Atrás 
La naturaleza de los negocios hoy en día está cada vez más descentralizada. El uso de las aplicaciones en la nube está creciendo de forma explosiva. Los datos están en todas partes. Y un gran número de usuarios continuará trabajando de forma remota incluso después de la COVID-19. Aunque todas estas cosas aumentan la agilidad del negocio, también aumentan la superficie de ataque de una organización. El concepto de confianza cero está generando mucho ruido como panacea para estas nuevas exposiciones al riesgo—y por una buena razón. Si se aplica correctamente, una arquitectura de seguridad diseñada en torno a la idea de confianza cero tiene el potencial de proteger contra las violaciones de datos, los ataques de ransomware e incluso las amenazas internas. Sin embargo, una confianza cero demasiado restrictiva y de grano grueso aumenta el potencial de una implementación fallida.
La reciente orden ejecutiva de la Casa Blanca sobre ciberseguridad se redactó en respuesta a la escalada de casos de violaciones de datos y ataques de ransomware. Una mentalidad continua de confianza cero es fundamental para los controles avanzados descritos por el presidente Biden—así como la necesidad de centrarse más en los datos. Esto significa que el acceso con menos privilegios debe aplicarse a cada decisión de acceso—donde las respuestas a las preguntas contextuales de quién, qué, cuándo, dónde y cómo, son fundamentales para permitir o denegar adecuadamente el acceso a los recursos.
Por qué la confianza cero necesita el contexto de los datos para tener éxito
Si todo lo que se sabe es la identidad del usuario, no se podrá llegar muy lejos con la confianza cero. Para aplicar con éxito controles que mantengan el negocio en funcionamiento al tiempo que se eliminan los riesgos, se necesita más información contextual tanto del usuario como de los detalles circundantes que implican cómo y por qué están interactuando con los datos y las aplicaciones de la organización. Esto puede incluir:
- ¿A qué grupo de la empresa pertenece el usuario?
- ¿Cuál es la postura de su dispositivo—es un dispositivo gestionado o no gestionado?
- ¿A qué recursos necesita acceder? ¿Se trata de una aplicación privada a la que necesitan acceder mediante un navegador?¿O necesita un protocolo especial de acceso a SSH porque es un administrador de sistemas?
- ¿Se trata de un contratista que trabaja en un proyecto y necesita acceso a la cuenta corporativa de Office 365 y a contenido específico para poder colaborar con las partes interesadas del proyecto?
- Una vez que le concede el acceso, ¿qué hacen?¿Qué actividades intentan realizar? ¿Están descargando datos? ¿Están subiendo datos? ¿Están compartiendo datos? ¿Están editando datos? ¿O están creando datos?¿Cuál es la naturaleza sensible de los datos?
También hay varias actividades diferentes que no sólo hay que supervisar, sino también establecer controles de confianza cero. He reunido cinco escenarios del mundo real en los que el contexto de los datos debería informar del nivel de confianza asignado al acceso de los usuarios. Son las siguientes:
Escenario 1: Los usuarios necesitan acceder a una aplicación interna o privada
El ejemplo aquí es un usuario del departamento de marketing que sólo necesita acceso de navegador al sistema de gestión de aprendizaje (LMS) de la empresa.Pero otro usuario del equipo de administración de sistemas necesita un acceso SSH especial para poder administrar el servidor que ejecuta la aplicación LMS.
La antigua forma de gestionar el acceso a la aplicación ha sido hacerla accesible al público o proporcionar acceso VPN. Pero este tipo de gestión deja la oportunidad de que los malintencionados obtengan acceso y se muevan lateralmente. Aunque ambos usuarios intenten acceder a la misma aplicación, es necesario tomar diferentes decisiones contextuales sobre el nivel de acceso que se concede a la aplicación LMS en función del grupo de la empresa específico del usuario.
Escenario 2: El usuario necesita acceder a una aplicación de almacenamiento en la nube popular, pero de alto riesgo
Otro usuario (también de marketing) quiere acceder a una popular aplicación de almacenamiento en la nube para poder subir y compartir datos rápidamente. Hay más de 2.400 aplicaciones en la nube que se utilizan en la empresa media. La mayoría de esas aplicaciones se utilizan fuera de TI, lo que significa que TI no tiene acceso administrativo. La preocupación que suscita el uso de este tipo de aplicaciones de Shadow IT es que pueden introducir oportunidades de pérdida de datos por parte de empleados descuidados o, tal vez, de empleados que pretendan robar datos, simplemente porque muchas de ellas carecen de las capacidades de seguridad adecuadas. ¿Realmente quiere que los datos sensibles se suban a una de estas aplicaciones? En el pasado, los responsables de TI se limitaban a bloquear el uso de las aplicaciones en la nube para cortar de raíz estos vectores de ataque. Pero las exigencias de agilidad del negocio y los efectos de la transformación digital hacen que los controles de acceso de grano grueso sean casi imposibles de aplicar.
A este mismo usuario le gusta la aplicación que ha elegido porque es realmente sencilla—sólo tiene que subir los datos del proyecto y compartirlos directamente con los socios de negocio.Así que la pregunta es ¿cómo incluimos este tipo de aplicaciones en la nube en un modelo de confianza cero? En primer lugar, tenemos que entender no sólo quién es el usuario y qué dispositivo está utilizando, sino también la naturaleza del riesgo que presenta la aplicación específica. ¿Se trata de una aplicación conocida y ampliamente utilizada, o de algo nuevo de un desarrollador menos establecido? ¿Ha implementado el proveedor de la aplicación las medidas de seguridad adecuadas? Tenemos que ser capaces de calcular el riesgo contextual de la aplicación. También necesitamos saber qué actividad se está realizando. ¿El usuario está simplemente accediendo a la aplicación o está realizando una actividad como subir información sensible de la empresa?
Escenario 3: Un usuario de riesgo quiere descargar datos
Digamos que tienes un contratista cuyo contrato está a punto de terminar con la empresa. Este usuario entra en su cuenta corporativa de Office 365 y descarga un montón de datos antes de dejar la empresa.Tal vez esté actualizando su portafolio de muestras de trabajo con documentos disponibles públicamente, o tal vez se trate de un interno malintencionado que roba información sensible en su camino de salida.
En el pasado, la gestión del acceso era todo o nada. Si el usuario en cuestión sigue siendo un contratista activo que necesita acceso a los datos para cumplir con sus deberes diarios en la empresa, probablemente tendría acceso continuo hasta que el puesto termine oficialmente. Los antiguos controles de acceso de grano grueso son esencialmente un interruptor de encendido/apagado.
Entonces, ¿cómo se pueden establecer controles de confianza cero más granulares en estas circunstancias de transición? En primer lugar, desde el punto de vista de la identidad, queremos saber que se trata de un contratista y no de un empleado a tiempo completo. Esa diferencia contextual puede ayudar a señalar que se trata de un escenario de mayor riesgo. A continuación, queremos saber más sobre la actividad específica que está realizando este usuario. ¿Está intentando descargar datos de una de nuestras aplicaciones en la nube? ¿Qué nos dicen las actividades anteriores de este usuario sobre su perfil de riesgo? ¿Ha realizado el usuario actividades de descarga como ésta antes? Tenemos que ser capaces de evaluar el riesgo y aplicar controles de acceso basados en estos factores contextuales.
Escenario 4: Movimiento de datos no intencionado o no aprobado entre cuentas de aplicaciones en la nube
En este escenario, un usuario descarga datos de la cuenta de OneDrive de Office 365 o de Google Drive del almacenamiento en la nube corporativo y sube esos datos a la misma aplicación de almacenamiento en la nube, pero a una cuenta no gestionada por TI. Esto puede ser o no un robo de datos. El usuario podría estar realizando este movimiento de datos de forma no intencionada, o tal vez se trate de un ejecutivo que roba secretos comerciales antes de dejar la empresa.
El contexto es clave para entender los detalles de la cuenta de la aplicación en la nube implicada tanto en la descarga como en la subida. ¿Se realizó la descarga inicial desde la cuenta de OneDrive de Office 365 gestionada por la empresa y posteriormente se subieron los mismos datos a una cuenta de OneDrive de Office 365 no gestionada por TI? ¿O se subió a la misma cuenta corporativa de OneDrive de Office 365 porque el usuario estaba colaborando en un proyecto? Sin el contexto de la instancia de la aplicación en la nube, se vería obligado a confiar en mecanismos como las restricciones de tenants admitidas por los proveedores de aplicaciones en la nube para bloquear simplemente todas las cuentas de Office 365 excepto la cuenta corporativa. Este enfoque no es ideal, ya que también podría estar bloqueando la productividad. Para este caso de uso, la evaluación del riesgo comienza con la comprensión de la instancia de la aplicación en la nube que está involucrada en la descarga y la subida y, a continuación, el establecimiento de controles basados en esa comprensión contextual para evitar las actividades de riesgo y bloquear el movimiento de datos sensibles sin ralentizar la productividad del usuario.
Escenario 5: Datos sensibles descargados en un dispositivo no gestionado
El último escenario tiene que ver con los dispositivos no gestionados: empleados que utilizan sus propias máquinas (BYOD) o contratistas de terceros que no tienen un dispositivo cedido por la empresa, pero que todavía necesitan acceder a las aplicaciones corporativas para hacer su trabajo. Puede ser un contratista que tenga un acuerdo con la empresa, pero eso puede no ser suficiente para justificar una confianza totalmente implícita. Es necesario dar a su dispositivo ciertos permisos, pero ¿qué nivel de acceso es el adecuado?
Antiguamente, el departamento de TI sólo concedía acceso a datos y aplicaciones a los dispositivos que controlaba. Con los dispositivos no gestionados, es posible que queramos restringir la capacidad de descargar ciertos tipos de datos sensibles.Saber más sobre el propio dispositivo se convierte en una aportación contextual muy importante.
Despliegue de la Confianza Adaptativa Continua con SASE
Lo que todos estos escenarios señalan es la necesidad del contexto de los datos para aplicar el concepto de confianza adaptativa continua. Necesitamos una seguridad que pueda analizar los hechos de una situación específica y tomar decisiones en tiempo real sobre los controles de acceso basados en los riesgos contextuales que se presentan. ¿Quién es el usuario? ¿Cuál es la postura del dispositivo que está utilizando? ¿Dónde se encuentra el usuario? ¿Cuál es el riesgo de la aplicación a la que está accediendo? ¿Es una aplicación en la nube gestionada por la empresa, una aplicación propiedad de una de las líneas de negocio o una aplicación de un socio? ¿O se trata de la cuenta personal de la aplicación en la nube del usuario? ¿Qué actividad se está realizando? ¿Se trata de datos sensibles? Estas preguntas deben hacerse para determinar si se concede o no el acceso inicial al recurso y también para verificar continuamente las actividades realizadas después del acceso inicial.
Aquí es donde es clave una arquitectura del servicio de acceso seguro en el borde (SASE) que soporte la confianza adaptativa continua. SASE es el mecanismo de entrega de la confianza cero, y la confianza adaptativa continua permite un punto de control más inteligente entregado por SASE. SASE permite trasladar el punto de control de la confianza cero a cualquier lugar en el que se encuentren el usuario y los datos. Esto es muy importante hoy en día—con usuarios que trabajan desde cualquier lugar accediendo a recursos en la nube, aplicaciones privadas y sitios web más allá de la visión local de TI, usted necesita la capacidad de SASE para mover el punto de control dondequiera que estén los usuarios y los datos.
El hecho es que los usuarios y los datos están ahora en todas partes. Más del 50% de los datos de una organización están ahora en la nube—y eso incluye una cantidad cada vez mayor de datos sensibles. Y, desgraciadamente, la mayoría de las organizaciones está ciegas frente a las actividades y amenazas en la nube—como el actual aumento del phishing en la nube, en el que los malintencionados utilizan aplicaciones en la nube para alojar datos de formularios diseñados para obtener las credenciales de los empleados. El ransomware también está en alza—los ataques han aumentado un 150% y la cantidad pagada por las víctimas ha aumentado más del 300%.
Una arquitectura SASE es la evolución natural que cambia la seguridad para seguir la naturaleza del negocio adaptable—permitiendo controles inteligentes y granulares basados en el contexto de los datos y eliminando los riesgos para la organización. Implementa un concepto de confianza cero sin rigidez restrictiva que se rompe en circunstancias del mundo real.
Este artículo fue publicado originalmente por United States Cybersecurity Magazine.
Lea el blog